<?php
/**
 * <https://y.st./>
 * Copyright © 2019 Alex Yst <mailto:copyright@y.st>
 * 
 * This program is free software: you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation, either version 3 of the License, or
 * (at your option) any later version.
 * 
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
 * GNU General Public License for more details.
 * 
 * You should have received a copy of the GNU General Public License
 * along with this program. If not, see <https://www.gnu.org./licenses/>.
**/

$xhtml = array(
	'<{title}>' => 'Next level at ...',
	'takedown' => '2017-11-01',
	'<{body}>' => <<<END
<img src="/img/CC_BY-SA_4.0/y.st./weblog/2019/07/05.jpg" alt="A lamp cover fallen down beside the lamppost" class="framed-centred-image" width="800" height="480"/>
<section id="diet">
	<h2>Dietary intake</h2>
	<p>
		For breakfast, I had 45 grams of cereal and 101 grams of soy milk.
		For lunch, I had a 390-gram smoothie.
		For dinner, I had 470 grams of potato gnocchi, chopped carrot, and the last of my cashew sauce.
		I won&apos;t be having any more for a while, as I have to get a whole tub of white miso to make any, and the miso takes quite a while to use.
		I&apos;m not sure how long it keeps, so getting it mean committing to cashew sauce for quite a while.
		I love the cashew sauce, but I&apos;d like to see what other recipes I can find.
		After work, I had a 394-gram smoothie.
	</p>
</section>
<section id="drudgery">
	<h2>Drudgery</h2>
	<p>
		My discussion post for the day:
	</p>
	<blockquote>
		<p>
			Images are made up of a number of so-called &quot;channels&quot;.
			Channels each present some part of the data of the image, and can be thought of as layers.
			In a decent image editor such as the $a[GIMP], you can edit each channel independently of the others, though you usually won&apos;t do that.
		</p>
		<p>
			In most non-palleted images, the main three channels represent the amount of red, green, and blue in each pixel of the image.
			Each channel offers each pixel a range of intensity values from <code>0</code> to <code>255</code>, with higher values representing there being more of the colour present in that pixel.
			Graphics $a[API]s tend to abstract away this integer-based system though, opting instead to use a float-based system with intensity values ranging from <code>0.0</code> to <code>1.0</code> (Cunningham, 2003).
			The concept is the same though: higher values ad more of the colour and lower values ad less of the colour.
			There are also greyscale images, which instead use a single channel to represent all three colours, making black, white, and grey the only colour options.
		</p>
		<p>
			But what about transparency?
			You could say that a fully-transparent pixel has no colour, so do we set red, green, and blue all to <code>0</code> for transparency?
			No, we still get colour in that case; we get the colour black.
			Besides, what about translucent (that is, <strong>*partly*</strong> transparent) pixels?
			We need a way to not only keep track of how transparent the pixel is, but also what colour the pixel has.
			Clearly, using the main three channels for transparency data just isn&apos;t going to work.
		</p>
		<p>
			Instead, we can add a fourth channel (or in the case of greyscale images, a second channel) dedicated to dealing with transparency information.
			That channel is called the alpha channel.
			Like other channels, the alpha channel assigns each pixel a value from <code>0</code> to <code>255</code>, but this time, the higher values represent higher opacity, while lower values represent higher transparency.
			At full transparency - an alpha channel value of <code>0</code> - the red, green, and blue channels don&apos;t even mater.
			They can&apos;t be seen in the slightest.
			Instead, whatever&apos;s behind the image is the only thing drawn at that pixel.
			At full opacity - an alpha channel value of <code>255</code> - nothing behind the pixel can be seen, and the colour of the pixel fully determines the colour that will be drawn at that point on your monitor.
			The alpha channel can be thought of as a mask (Beal, n.d.), covering up the pixel partly (or fully) with transparency.
			As our textbook says, this too usually gets abstracted away by graphics $a[API]s, which use the same <code>0.0</code> to <code>1.0</code> as they do for the colour channels.
		</p>
		<p>
			The way the alpha channel is implemented in graphics libraries is that object pixels with less than <code>1.0</code> only partly overwrite the previous values in the buffer (Cunningham, 2003).
			This makes it important that you render your objects from furthest to nearest.
			Otherwise, the further objects won&apos;t be rendered because they&apos;ll be detected as being behind the transparent object that already rendered, and if they did render, they&apos;d overwrite the transparent object and appear closer than it.
			Drawing objects in this order also allows transparent objects to properly stack with one another, so you can see several transparent objects behind one another.
		</p>
		<div class="APA_references">
			<h3>References:</h3>
			<p>
				Beal, V.
				(n.d.).
				<a href="https://www.webopedia.com/TERM/A/alpha_channel.html">What is Alpha Channel? Webopedia Definition</a>.
				Retrieved from <code>https://www.webopedia.com/TERM/A/alpha_channel.html</code>
			</p>
			<p>
				Cunningham, S.
				(2003).
				<a href="https://www.cs.csustan.edu/~rsc/NSF/Notes.pdf">Computer Graphics: Programming, Problem Solving, and Visual Communication</a>.
				Retrieved from <code>https://www.cs.csustan.edu/~rsc/NSF/Notes.pdf</code>
			</p>
		</div>
	</blockquote>
</section>
<section id="Minetest">
	<h2>Minetest</h2>
	<img src="/img/CC_BY-SA_3.0/minetest.net./weblog/2019/07/05.png" alt="Elemental levels" class="framed-centred-image" width="1024" height="600"/>
	<p>
		I&apos;ve been working on a level-showing menu page so players can see their proficiency level with various elements.
		That sort of became my project for the day.
		Unfortunately, I started thinking about how this could be generalised.
		It doesn&apos;t have to be specific to the Building Up From Zero mod.
		And you know what that means: it&apos;s time to break that menu off the main mod and turn it into its own mod.
		The problem with this is that as its own mod, it&apos;s more important for it to do its now-singular job well.
		And what kind of level-display mod wouldn&apos;t show players how many more drops they need to reach the next level?
		And to do that, I need to be able to calculate how many of a drop are needed to reach the level just after the one the player&apos;s at, then subtract their current drop count from that.
	</p>
	<p>
		The maths are sound.
		That&apos;s not even the problem.
		Like, when I was trying to build the level-calculation code originally, I accidentally built it in reverse, so it gave me the number of stacks you need given a level you&apos;re at, which is exactly what I needed now.
		All I had to do was flip the numerator and denominator when calculating the exponent, and now that I&apos;m deliberately trying to reverse the calculation, swap <code>math.floor()</code> for <code>math.ciel()</code>.
		However, there&apos;s the problem of precision.
		I&apos;ve already seen that the level code doesn&apos;t work perfectly.
		Due to precision loss, it take more stacks then intended to reach the highest level.
		It&apos;s not a big deal, and I wasn&apos;t even going to bring it up, as it wasn&apos;t relevant until now.
		However, with this loss of precision, I can only assume that the inverted exponent will have the same loss of precision, and it&apos;s possible that the combined precision loss could set the two conversions to not be exact inverses of one another.
		And if they&apos;re not exactly inverses, the &quot;next level at&quot; code won&apos;t work correctly.
	</p>
	<p>
		I set up <code>minestats</code> to calculate the reverse exponent when it was calculating the forward exponent (that&apos;s really the best time, as it has both the numerator and denominator in hand and can simply reverse them instead of needing to recalculate and reverse them later), without making those exponents usable outside the mod, then ran some tests.
		Thankfully, all one hundred levels available for max-99-capped elements works perfectly.
		That&apos;s good enough for me.
		My current use cases are 99-capped elements and 65535-capped elements, and 65535-capped elements have the same numerator as denominator in the equation, so the exponent turns out to be one, which is its own inverse.
		I might go through and do more-through testing later, but for now, this works great.
		With the new $a[API] call set up, I built the new break-off mod.
		The interface could probably use some work, but it functions about how I want it to function.
		You can&apos;t see all your upcoming levels at once, but you can see the eight that you&apos;re closest to, or if used with the vanilla game, you can see the ten that you&apos;re closest to, as the missing six elements free up another row.
		One of the great things about only showing the level-ups you&apos;re closest to is that it encourages you to go after the levels you&apos;re closest to attaining, which will often be your lowest levels, so it encourages well-rounded mining/farming, at least up to a point.
		At the same time though, all the elemental level meters are clickable.
		Clicking one shows you how close you are to the next level for that element.
		So while you&apos;re sort of nagged a bit to pursue the levels you&apos;re closest to achieving, you&apos;re still free to check on any level you choose to and work specifically on that element.
	</p>
</section>
END
);
